Jump to content

Template talk:Category series navigation/Archive 1

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1Archive 2Archive 3

Problem in navigation

As can be seen on Category:2008–09 I-League, the template create 2009-010 instead of 2009-10 in the navigation. Can anyone take a look? Coderzombie (talk) 05:20, 14 July 2016 (UTC)

checkY Thanks for catching that - I spent a lot of effort sorting out the complicated stuff that happens around the year 2000, but didn't check every one of the simpler cases! Le Deluge (talk) 10:51, 14 July 2016 (UTC)

LinkCatIfExists2 option or default?

This template is used over such a wide range of WikiProjects, so asking here.
Le Deluge (and anyone else), what would you think of using {{LinkCatIfExists2}} so that redcats are instead greyed out (example via {{Category in year}} here), either as default, or as a parameter option using |linkcatifexists2=yes, |grey=yes, |gray=yes, |blueonly=yes, or the like.   ~ Tom.Reding (talk ⋅dgaf)  13:48, 3 October 2018 (UTC)

@Tom.Reding:I know it requires some WP:IARing of WP:REDNOT, but I would oppose having it as a default. Personally I use those red links all the time for creating new categories, and my heart rather sinks when I come across something that uses {{Year by category}} which greys them out so I can't just click to create a needed new category. I guess it's a question of balancing the needs of "readers" and those actively editing the categories. In general the year categories are not heavily used - when testing this it was easy to find categories that get <10 views per YEAR, so one could argue that they're more "plumbing" than "front of house" so needn't be held to the same standards of prettiness. I'm open to the conversation, but that would be my view. One could equally say that if there are significant numbers of red links within a decade, then you're probably looking at something that should be categorised by decade rather than by year.Le Deluge (talk) 22:36, 3 October 2018 (UTC)
@Le Deluge: generally, I completely agree. However, specifically, there are times when certain categories will never be created, such as taxonomy categories prior to Category:Birds described in 1758 and Category:Plants described in 1753, and sometimes intermittent years after if no publications were made. I think I've just answered my own question though, with a parameter being the best choice.   ~ Tom.Reding (talk ⋅dgaf)  11:17, 4 October 2018 (UTC)
@Tom.Reding: If categories will never be created because they are before some event (like foundation of a country etc) then they don't want greying out, they shouldn't be shown at all. That implies a parameter to set a start date - I think someone has done something similar with the big 100xyear-in-country navboxes for the country century cats. In fact it would be better to set an end date, as you could then reuse the code to be a bit more intelligent in relation to CURRENTYEAR. At the moment it ends at CURRENTYEAR +1 for decades but not years or seasons, as links to the 2040s are clearly daft, whereas links to 2021 are more common than you might think (I've just done cats relating to a 2022 handball tournament). I'll have a think of the best way to handle those intervening years - I've got some ideas on using LinkCatIfExists to handle some other edge cases, like the way Argentinian football went from seasons to years to seasons again. In the meantime, one can always use {{Year by category}} if it bothers you that much, as that does grey out links. But to be honest, if taxonomy was at such a primitive stage that species weren't being described every year, then a decade category is probably more appropriate. Personally I think that whole hierarchy should be nuked - when you look at a panda, is "It was described in 1869" one of the first 3-4 things that pops into your head? To my mind year of description is not WP:DEFINING, so shouldn't be used as a category. Although I'm not sure I'm going to have much luck persuading taxonomists of all people not to use too many categories! Le Deluge (talk) 13:46, 4 October 2018 (UTC)
@Le Deluge: Module:Category described in year (the main reason for my coming here) actually used to use a variant of {{Year by category}}, but both are kind of clunky, and I like this one you've created much more since it 1) is automated, 2) is simple to use, 3) looks better imo, and 4) displays 11 cats instead of 10, 5 on either side of the target, improving navigational consistency.
The variant, {{Category in year}}, is an improvement/simplification of {{Year by category}} as it relates to taxonomy, but still uses the same base, so it can only go so far. One of those simplifications is the use of a |min= parameter too, but its use is/was intermittent in the taxonomy area, so it could go either way. Personally, I wouldn't choose to enforce/use a |min= param if it were available, after seeing the alternative (this template). Decade cats are their own can of worms, arguably the worst being that YY00 cats would be duplicated/misplaced in their parent century container cats. I'm actually in the process of ridding the taxonomy area of decade cats after a recent RfC. Also, just because one year doesn't exist doesn't mean adjacent years are sparse - some years adjacent to reds contain ~100 pages.   ~ Tom.Reding (talk ⋅dgaf)  14:25, 4 October 2018 (UTC)
@BrownHairedGirl: fyi in case you didn't see this discussion.   ~ Tom.Reding (talk ⋅dgaf)  01:50, 13 October 2018 (UTC)
@Tom.Reding: No, I hadn't seen it. Thanks for the ping.
Maybe I should have msged you before making LinkCatIfExists2 std usage, but it seemed to me to be a bit of a no-brainer, and that you had prob just been testing. Sorry if that came across as rude.
@Le Deluge: I think WP:REDLINK/WP:REDNOT is fairly clear about this sort of thing. We don't create categories unless there is content to populate them, so a cat should be redlinked only if it is to be created now. That its not the case in most of these series, which is why {{LinkCatIfExists2}} is now deployed on ~250,000 pages. You are the first editor who I have ever seen object to it, and I'm surprised by the need you express. It takes only a second or two more to edit the URL and create a new category that way, so editors are barely impeded -- and even if usage is low, these are not maintenance cats. They are created for readers, and their display should not be compromised to save editors one or two keystrokes (literally one or two).
Tom, I have long cursed {{Year by category}} as insanely crude. {{Category in year}} is much better. I have long had in mind to supersede them both (and their many variants) with a single backward-compatible swiss-army-knife year-cat-nav template which does parent cats etc, but also is smart enough not to need year parameters in most cases (and never the cursed m=/c=/d=/y= stuff). Navseasoncats has its uses and is brilliantly flexible, but there are many cases where something which does parent cats is better. Would you be interested in working together to spec and build that swiss-army-knife year-cat-nav? --BrownHairedGirl (talk) • (contribs) 04:54, 13 October 2018 (UTC)
@BrownHairedGirl: you've certainly given the situation more thought than I! I'm not familiar with the whole constellation of catnav templates, only the ones that tend to show up in my areas of interest, so you'd have to take the lead on that. What I have day dreamed about was converting this template to a Lua module, with each subpage its own function, but then I figured 'if it ain't broke don't fix it'. Any overarching, backwards-compatible, swiss-army-knife would have to be written in Lua though (I mean it could be written in template markup, but it would be vastly more tedious to write, let alone debug months later, or maintained by another editor). I'd help for sure, once there's a relatively complete list of features to sort out.   ~ Tom.Reding (talk ⋅dgaf)  13:12, 13 October 2018 (UTC)
@Tom.Reding: yes, the Swiss Army knife would have to be built in Lua, or else many editors would go mad trying to build and/or maintain it. But I agree, big project. Maybe I'll come back to it when winter sets in, and try to gather a few people together to agree features.
I do like the idea of Luafication of this template. I think @Le Deluge has expertly stretched parser functions very far here, but that a Lua rewrite would resolve the few probs which LD noted in edge cases. --BrownHairedGirl (talk) • (contribs) 14:04, 13 October 2018 (UTC)

Template-protected edit request on 22 March 2019

Moved from Template talk:Navseasoncats/var firsthalf
 – * Pppery * has returned 00:43, 22 April 2019 (UTC)

Please remove the line <noinclude>{{pp-template|small=yes}}</noinclude> - protection templates are automatically handled by the documentation page. Thanks, --DannyS712 (talk) 07:14, 22 March 2019 (UTC)

Done — JJMC89 (T·C) 07:24, 22 March 2019 (UTC)

min & max parameters for decade and/or hyphen cats?

I see that |min= & |max= currently only work for navyear type cats, but not navdecade & navhyphen cats. Is there any desire to add this functionality to either of these other category types?   ~ Tom.Reding (talk ⋅dgaf)  20:52, 14 April 2019 (UTC)

@BrownHairedGirl: any thoughts on this?   ~ Tom.Reding (talk ⋅dgaf)  12:52, 17 April 2019 (UTC)
Yes, Tom.Reding, I am v keen to have something like that.
However, I have parked it for now, because I think that what we really need is a major all-Lua rewrite of navseasoncats, which I have already sketched offline in outline. What we really need is a clear definition of what we want max and min to do in these cases, and to have consistent behaviour across all cases.
@ Fayenatic london has also given a lot of thought to these issues. --BrownHairedGirl (talk) • (contribs) 13:02, 17 April 2019 (UTC)
@BrownHairedGirl: FYI {{Navseasoncats}} is now all-Lua!   ~ Tom.Reding (talk ⋅dgaf)  13:08, 17 April 2019 (UTC)
Also I'm curious to see your outline when complete.   ~ Tom.Reding (talk ⋅dgaf)  14:34, 17 April 2019 (UTC)
@BrownHairedGirl: |min= & |max= parameters now work for all decade cats AD/BC (but not BCE yet - are there any BCE decades?). Under the principle of least astonishment, they behave similarly as on year & ordinal categories, while navdecade behavior was otherwise left unchanged. Behavior can be changed in the future with the modification of a few constants. This was a relatively simple (other than two 0s decades situation) transfer of the min/max code from navyear/navordinal, but doing this for navseason I think would be even trickier, so that won't be done on a whim. There's also the question of whether to adopt decade's shifting behavior for seasons, or if they're to remain centered like years & ordinals.
Somewhat related: is there a use-case for making navseasons work below AD 100, and possiblyyes: Category:Taxonbars with 30–34 taxon IDs for BC/E? Any examples would be helpful, though I hope none exist b/c I haven't been looking forward to doing that...   ~ Tom.Reding (talk ⋅dgaf)  19:36, 4 May 2019 (UTC)

Millennia

On a millennium category such as Category:3rd millennium in Egypt, there is no point showing future millennia, and it would be better to reach back to 4th millennium BC which exists in that case. I therefore suggest that all millennia categories display the range from 4th BC to 3rd after. – Fayenatic London 10:48, 4 May 2019 (UTC)

@Fayenatic london: I agree, but only for "specific" millennium cats like X millennium in Y, X millennium people, etc., since "bare"/"general" millennia currently go up to the 10th millennium. And |min=/|max= would be made to override these defaults, of course.   ~ Tom.Reding (talk ⋅dgaf)  12:26, 4 May 2019 (UTC)
The only exception I see to the "specific" cat rule would be Category:10th millennium in fiction Category:Fiction set in the 10th millennium. If many (or any?) more exceptions arise, that would be an argument to maintain the standard functionality.   ~ Tom.Reding (talk ⋅dgaf)  13:02, 4 May 2019 (UTC)
Thanks. I see that (dis)establishments, architecture & "buildings and structures" go further back than 4th BC, so I guess there is no call to standardise the min. But I would favour defaulting the max to 3rd. – Fayenatic London 13:43, 4 May 2019 (UTC)
 Done   ~ Tom.Reding (talk ⋅dgaf)  00:38, 7 May 2019 (UTC)

Roman numerals & ordinal words

Split off from the above discussion/request

I first need to be able to go backwards and forwards from words/numbers to numbers/words. This is currently almost completely doable:

  • 2019 → MMXIX via {{Roman|2019}}
  • MMXIX → 2019 via {{#invoke:ConvertNumeric|_roman_to_numeral|MMXIX}}
  • 1 → first via {{Ordinal to word|1}}
  • first → 1 via ??? {{#invoke:ConvertNumeric|_english_to_ordinal|First}} (produced as a result of this discussion)

I could not easily find a word-to-ordinal utility (it's possible I glossed over it), and Template:Word to * & Module:Word to * don't exist (yet).

Questions to Gonnym, Fayenatic london, and everyone else:

  1. Do you know if a function like this exist somewhere?
  2. Could you link to any examples of Roman numeral & ordinal word categories?

~ Tom.Reding (talk ⋅dgaf)  16:58, 8 June 2019 (UTC)

  1. Sorry, I do not know.
  2. Category:Members of the Chamber of Deputies (Kingdom of Italy) by term and Category:Members of the Verkhovna Rada by term. – Fayenatic London 17:24, 8 June 2019 (UTC)
I think that Module:ConvertNumeric can be set up to handle that. It already has the mappings of 0-19 and 10-90, etc. So basically, what the code will need to do is:
  1. Take a string - so "thirty fourth";
  2. Split it to substrings by spaces - so "thirty" and "fourth";
  3. Calculate how many substrings you have for next steps;
  4. Use a substring to do a reverse search in a table (decided by the substring count) by the "value" to find the "key" - so "thirty" = "30" and "fourth" = "4";
  5. Sum the total - so "34".
This is a very general overview, but I'm sure something like this can work. --Gonnym (talk) 18:01, 8 June 2019 (UTC)
 Roman numerals done.
 Ordinal words on hold. I want to be cautious about these b/c they're much more computationally intensive, and will take many more lines of code to find, than a simple 1 or 2-line regex pattern. To grab the entire 'varseason' (now 'findvar'), one must send each word of the category name to match any possible numerical word, not to mention going the other way and converting to a number. Perhaps I can do this at the end of the search, to be done only after all other category types have been exhausted. But before I do, I'd want to limit the max ordinal to something reasonable, like below 100, meaning that I wouldn't want to implement this if there are large ordinal cats out there. The largest I quickly found was Category:Thirty-first Dynasty of Egypt‎, and there were no results for categories starting with 'Thirty-third'. If the maximum ordinal word cat is < 40, then that will be ok.   ~ Tom.Reding (talk ⋅dgaf)  03:47, 12 June 2019 (UTC)
Not arguing for or against this feature, but just to clear some things up. The code shouldn't care if the numbers are up to 40 or 99, as the tables and code is set up to work with certain unique ranges. So numbers 1-19 have their own table and 20-90 have another table. If you go up to 40, then it doesn't matter if it's 90 (or 99) as the table checks the tens. So it can be 30 or 50, it doesn't matter. Now since 99 is 90 + 9, then again, that is the same as the previous code. All this is handled by numeral_to_english_less_100(). If you go above 100 then that is just a little more process that goes into with numeral_to_english_less_100(). --Gonnym (talk) 09:47, 12 June 2019 (UTC)
 Wordinals done.
I chose a limit of 100 because all lower ordinals are simply 1 word, possibly hyphenated. This is the simplest case, and luckily I couldn't easily find higher examples, so 1–99 is probably sufficient. While decoding strings like 'one hundred and first' is doable, searching for the whole phrase would add a non-trivial amount of complexity to {{Navseasoncats}}. If working examples are found, p.find_var and nav_wordinal functionality can be extended.   ~ Tom.Reding (talk ⋅dgaf)  02:15, 14 June 2019 (UTC)
Nice work, Tom! If any cases are found above 100, the strings may have to cope with WP:ENGVAR e.g. hundred-first … but there are none at present.
[Documenting an issue unrelated to the template: Roman numerals before 40 sort in the correct order except for the nines, i.e. those ending IX. In the above category, I replaced IX with VIIII in the sort keys in order to sort after VIII.]
– Fayenatic London 09:02, 19 June 2019 (UTC)

Year ranges straddling centuries

The template works for e.g. 1999–2000 but does not currently link to 1999–2004, see Category:MEPs 2004–09. – Fayenatic London 08:36, 27 May 2019 (UTC)

@Fayenatic london: {{Navseasoncats}} currently looks for MEPs 1999–04, which doesn't exist, but MEPs 1999–2004 does exist. I can make it show the full year after a century transition. Currently, the full ending-year is only used in shallow straddling cases like 1999–2000; this is the first deep century-straddle I've seen. Is this behavior written somewhere or just an ad hoc convention?   ~ Tom.Reding (talk ⋅dgaf)  13:24, 27 May 2019 (UTC)
MOS:DATERANGE is against two-digit ending years if it's not two consecutive years. --Gonnym (talk) 13:51, 27 May 2019 (UTC)
It looks like a large CfD is in order for almost all ~203 subcats of Category:Members of the European Parliament by term...   ~ Tom.Reding (talk ⋅dgaf)  18:28, 27 May 2019 (UTC)
Well, that would be one way round the problem. However, two-digit ending years are permitted by MOS:DATERANGE and common within Category:Legislators by term; it's not only MEP categories that use this format.
Nevertheless, perhaps it would be appropriate to manually construct separate nav category templates for each legislature. European Parliaments have been on fixed 5-year terms since 1979, but there were 2 sessions of irregular duration before that. If you were to fix the deep century-straddle, navseasoncats would work for Category:MEPs 1994–99 onwards, but not for earlier dates. Some other legislatures have even less regularity.
It's nice that it works with ordinal indicators like "1st". Can it also be made to work with ordinal numbers like "first", like Category:Members of the Verkhovna Rada by term?
How about Roman numbers, e.g. Category:Members of the Chamber of Deputies (Kingdom of Italy) by term? – Fayenatic London 21:34, 27 May 2019 (UTC)
@Fayenatic london: two-digit ending years are permitted, but only for consecutive years, and for 2 other exceptions which I don't think the parliamentary cats satisfy (random RS examples 1 & 2 which use full year beginning & ending years). If there are a significant # of RS using two-digit ending years, I'm happy keeping things as-is, but that doesn't seem to be the case.
I set my AWB to fully recurse Category:Legislators by term about 30 minutes ago and it's still going, but this PetScan worked to a depth of 4 (5 kept crashing) and returned ~700 cats with two-digit ending years.
Both "first" & roman numerals should be doable, as they would likely share code, just working off different tables. They would have to be hard coded (I suppose a text-ordinal/Roman numeral parser could be implemented, but it's probably not worth the effort...), so it would only be able to go up to some reasonable size - "fiftieth"/L should be high enough? The table would be intuitively extendable by hand as/when needed.   ~ Tom.Reding (talk ⋅dgaf)  12:20, 29 May 2019 (UTC)
Should see if Module:ConvertNumeric can help as I know it has a roman_to_numeral function. --Gonnym (talk) 13:01, 29 May 2019 (UTC)
 Done with the original request.
I'll also make it allow both "2000–05" & "2000–2005" style cats for non-consecutive years, in that order, and pick the first one found. While the MOS is a guide for article contents, WP:NCDURATION is purposefully vague, but it still points to the MOS, so it could go either way, or perhaps it will always be in limbo. We somewhat-similarly allow non-en-dashed ranges in the nav, but track them for follow-up. Which (or both?) non-consecutive format(s) we choose to track will be determined by the outcome of the CfD (compiling now).   ~ Tom.Reding (talk ⋅dgaf)  17:19, 29 May 2019 (UTC)
I'll point though that subject level guidelines always supplement the MoS but can never contradict it. So that guideline being vague isn't at all vague, but just does not repeat what the MoS already says about it. I think the best option would to do a CfD/RfC on this. --Gonnym (talk) 17:56, 29 May 2019 (UTC)
I suggest it should pick the full 4-digit dates if found. There may be a 2-digit date page as a redirect. Ah, Wikipedia talk:Categories for discussion/Log/2019 May 29 shows I'm wrong about that at the moment. – Fayenatic London 00:07, 31 May 2019 (UTC)
@Fayenatic london: given the success of the CfD, I decided to do as you suggest & search for the MOS-correct format first, with a fallback to the abbreviated format & subsequent tracking. Also, I added the feature of following {{Category redirect}}s & subsequent tracking.   ~ Tom.Reding (talk ⋅dgaf)  15:01, 7 June 2019 (UTC)
@Tom.Reding: Good work so far, thanks! How can we use min= in Category:MEPs 1979–1984, please? – Fayenatic London 17:45, 8 June 2019 (UTC)
@Fayenatic london: thank you. I raised that question above in #min & max parameters for decade and/or hyphen cats? with BrownHairedGirl. I'm not aware of any intervening discussions elsewhere, but, barring those, and at the risk of forking said discussion, I don't see a problem with navhyphen |min= & |max= having the same simple behavior as the other category types (i.e. no offsetting).   ~ Tom.Reding (talk ⋅dgaf)  20:19, 8 June 2019 (UTC)
​​ Sorry, either I don't understand how to use the parameters, or they don't work in this case. – Fayenatic London 20:40, 8 June 2019 (UTC)
It's the latter - currently (for a limited time), min/max are disabled for categories with a hyphenated range.   ~ Tom.Reding (talk ⋅dgaf)  20:47, 8 June 2019 (UTC)
 Done - |min= & |max= now available for hyphenated cats.   ~ Tom.Reding (talk ⋅dgaf)  15:30, 10 June 2019 (UTC)
Thank you, Tom. for the record, the above example simply takes |min=1979. – Fayenatic London 08:10, 11 June 2019 (UTC)

@ Wikipedia:Categories for discussion/Log/2019 May 29#Category:MEPs 1952-58, posted here separately for visibility.   ~ Tom.Reding (talk ⋅dgaf)  22:10, 29 May 2019 (UTC)

Follow-up CfD?

  1. Ghanaian MPs 1965–66
  2. Greek MPs 1868–69
  3. Greek MPs 1905–06
  4. Greek MPs 1924–25
  5. Greek MPs 1932–33
  6. Greek MPs 1935–36
  7. Greek MPs 1950–51
  8. Greek MPs 1951–52
  9. Greek MPs 1963–64
  10. Greek MPs 1989–90
  11. Haryana MLAs 1966–67
  12. Irish MPs 1557–58
  13. Irish MPs 1585–86
  14. Irish MPs 1634–35
  15. Irish MPs 1692–93
  16. Irish MPs 1713–14
  17. MEPs for Croatia 2013–14
  18. MEPs for Spain 1986–87
  19. Moldovan MPs 1917–18
  20. Moldovan MPs 2009–10
  21. Nagaland MLAs 1974–75
  22. Nagaland MLAs 1987–88
  23. Northern Ireland MLAs 2016–17
  24. UK MPs 1801–02
  25. UK MPs 1806–07
  26. UK MPs 1830–31
  27. UK MPs 1831–32
  28. UK MPs 1885–86
  29. UK MPs 1922–23
  30. UK MPs 1923–24
  31. UK MPs 1950–51

@Oculi, Gonnym, Philip Stevens, Lugnuts, FoxyGrampa75, and Concus Cretus: pinging everyone involved with the above CfD. Of the ~821 term-categories, 31 of them (~4%) have term lengths of exactly 1 and follow the (optional) YYYY-YY format, so they stand out a little amongst the vast majority of 2+ year terms with the unabbreviated YYYY–YYYY format. Since I can see arguments both for and against, what's the sentiment for formatting all of these YYYY–YYYY, regardless of term length?   ~ Tom.Reding (talk ⋅dgaf)  13:01, 8 June 2019 (UTC)

Special:WhatLinksHere/Category:MEPs_for_the_Republic_of_Ireland_2009–14 shows that the updated adjacent categories Category:MEPs for the Republic of Ireland 2004–2009 and 2014–2019 are in some way linking to the otherwise obsolete redirect at the 2-digit date. Is this a minor bug in the module? – Fayenatic London 09:20, 19 June 2019 (UTC)

I'm not sure why that is. If it was {{Navseasoncats}} related then you'd expect (in this case) 5 adjacent MEP cats in the WhatLinksHere; instead there are only 2. I null edited both of them, but they still show up, so I'm out of ideas.   ~ Tom.Reding (talk ⋅dgaf)  10:35, 19 June 2019 (UTC)
Right. The links are only appearing from adjacent categories, but do not appear from an adjacent category that straddles a new century, e.g. Special:WhatLinksHere/Category:MEPs_for_the_Republic_of_Ireland_2004–09 has a link from 2009–2014 but not from 1999–2004. Hence I assumed it was connected to recent changes… Ah, but no, it was the categories rather than the template that were changed on this point! – Fayenatic London 12:44, 19 June 2019 (UTC)
@Fayenatic london: I think I figured out why. When mw.title.new is used to check the existence of a category, it counts as a link to that page. I've updated the gap checking routine to check the most likely name first, so a multi-year range will first check an unabbreviated multi-year adjacent range, then, if not found, check the MOS-incorrect abbreviated multi-year adjacent range. Likewise, a single-year range first check an abbreviated adjacent range, then, if not found, will check the unabbreviated range (both MOS-acceptable). This should have been updated after MOS:DATERANGE CfDs, but was overlooked. This should lower the number of attempts, on average, needed to find the nearest existing cat, and can be optimized even more to start with whatever format the parent category is using, then, if not found, try the other one.   ~ Tom.Reding (talk ⋅dgaf)  16:14, 20 June 2019 (UTC)
Thanks again, Tom. Some links are still showing to the old categories deleted per Wikipedia talk:Categories for discussion/Log/2019 May 29, but at least we know we can ignore those links. @JJMC89: thanks for all the checking and deleting that you did on those legislators categories. – Fayenatic London 19:31, 20 June 2019 (UTC)
 Residual links removed   ~ Tom.Reding (talk ⋅dgaf)  15:33, 22 June 2019 (UTC)

Requested move 25 May 2019

The following discussion is an archived discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. No further edits should be made to this section.

No consensus to move, after extended time for discussion. Notably, even among those who supported a move, there was no clear determination of a move target. bd2412 T 19:14, 24 June 2019 (UTC)

– This template started as a category navigation tool for football seasons, but with the recent changes this has become a multi-style navigation tool, as can be seen by the doc at Template:Navseasoncats/doc#About. The name of the template should describe what it does and "navseasonscats" does not do that. Gonnym (talk) 10:32, 25 May 2019 (UTC) --Relisting. Steel1943 (talk) 13:48, 4 June 2019 (UTC)

@Gonnym's proposed name merely describes the type of template is. This is a not a generic category navigation template. It specifically does series by years decade and seasons, whereas the proposed name falsely labels it as a universal tool.
The current name doesn't describe all of that, but it describes some of it, and it is unique, concise and well-established. Gonnym's proposal does not describe what it does, and any alternative which actually describes its functionality is going to be much more verbose, e.g. Template:Category navigation by year, decade or season.
One of the advantages of {{Navseasoncats}} is is that its name is concise and unique, which makes it easy to use. There is no benefit to anyone in turning its name into either a misleading generic term, or into an essay. --BrownHairedGirl (talk) • (contribs) 16:52, 25 May 2019 (UTC)
How is my proposed name misleading while the current name fine? How are Category:2020s awards, Category:1999 in Scotland, Category:2000 United States presidential candidates, Category:Taxonbars with 30–34 taxon IDs, Category:1st Lok Sabha members or Category:2nd-century rabbis "by seasons" categories? There is exactly one type that is "by seasons" while the rest are clearly not. Also, please AGF and don't patronize by belittling other editors. the nominator si clarly unfamiliar with the v wide range of category navigation templates already in use. (sic), you'd be surprised, but I know how to read. --Gonnym (talk) 17:58, 25 May 2019 (UTC)
@Gonnym, I did AGF. I assumed that you would not do anything so daft as to propose the generic name "Category navigation" if you were already aware that there are dozens, possibly hundreds, of other templates which could be described by that title. But I accept your assurance that my good faith in your ability to spot the folly of a massively ambiguous title was misplaced.
The word "Season" can mean a broad period of time, so its use for years and/or decades isn't wrong, just not the primary meaning. But your proposal strips out any reference to periods of time, and proposes a title which could apply equally well to e.g. {{AllIrelandByCountyCatNav}}. I look forward to your explanation of why you think it is any way helpful to remove from the title any reference to time or series, and to use a massively ambiguous title.
If you are concerned by the lack of a specific mention of all the available time periods, then the solution might be to change the name to something like {{NavTimeCats}} or {{NavYearDecadeSeasonCats}} or {{NavNumberedSeriesCats}} or {{NavSequenceCats}} or something like that. But I don't see how the extra verbosity of the longer terms or the shift in focus of the shorter names would help anyone. --BrownHairedGirl (talk) • (contribs) 20:57, 25 May 2019 (UTC)
This will probably be the last time I respond to you, as you are a very unpleasant editor to deal with (But I accept your assurance that my good faith in your ability to spot the folly of a massively ambiguous title was misplaced. and I truly hope that in real life your attitude to others is much less vain. There is nothing wrong with an ambiguous title, as can be seen by WP:PRIMARYTOPIC, in this specific case, this template does indeed fit the criteria in that it's scope is already pretty large, while the other templates have a very specific and smaller scope. As such, the name I proposed works. That being said, and as I previously said at the very start of this thread, I was never against an alternative and better proposal. And while you can argue that "seasons" means that, it really doesn't, which is why "seasons" is not a good name and neither are your CamelCase proposals per WP:TPN and general recent practice. --Gonnym (talk) 21:08, 25 May 2019 (UTC)
Oh dear. WP:PRIMARYTOPIC is part of the policy on article titles. This is a template. --BrownHairedGirl (talk) • (contribs) 22:03, 25 May 2019 (UTC)
The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page. No further edits should be made to this section.

Category:Aircraft piston engines 1920-1929 moved

The category (and similar ones) has been moved. Could somebody please update the description. Thanks.

@Ymblanter: none of Category:1920s aircraft piston engines series have descriptions.   ~ Tom.Reding (talk ⋅dgaf)  16:41, 28 June 2019 (UTC)
@Tom.Reding: if I understand it correctly they are now transcluded via redirects.ay be one can choose another example, because if I now delete the redirects we are going to get red links.--Ymblanter (talk) 17:04, 28 June 2019 (UTC)
@Ymblanter: I've removed this cat series from the documentation. Did that help? It was being used as an example for the |testcasegap= parameter.   ~ Tom.Reding (talk ⋅dgaf)  17:28, 28 June 2019 (UTC)
Great, thanks.--Ymblanter (talk) 17:32, 28 June 2019 (UTC)

Using category redirects to bridge adjacent series

Currently, multi-year/hyphenated cats can search for and follow {{Category redirect}}s. 2 questions arise:

  1. Extend this behavior to all category types?
  2. Should we promote the use/creation of redirects 'linking' 2 different (but related) category series, like Category:Falkland Islands Councillors 2009–2013 & Category:Falkland Islands MLAs 2005–2009? I like this functionality, but I've also seen the category #Rs of the recent CfDs get deleted, so I'm not sure if it goes against any guideline (which would be worth making an exception for this, if needed, imo).

See Category:Navseasoncats range redirected (base change) for more.   ~ Tom.Reding (talk ⋅dgaf)  14:43, 15 June 2019 (UTC)

Wow! I see what you mean, given those examples. Navseasoncats links to the actual succeeding category, using an updated name, if there's a redirect at the default name (matching the old name). I think this is a very good feature.
Category redirects certainly can be kept where useful. We currently only have my recent essay on this point, WP:Category redirects that should be kept.
However, I note that in order to fully populate the template e.g. at Category:Falkland Islands MLAs 2009–2013, we'd have to create redirects at pages which are even more anachronistic, e.g. Category:Falkland Islands MLAs 2001–2005 and earlier. These would be vulnerable to good-faith deletions. Might it be better to add optional parameters for preceding/succeeding categories?
Or are we just trying to do too much? {{Preceding category}} & {{Succeeding category}} can provide navigation from adjacent categories, although not for more distant jumps. – Fayenatic London 20:40, 18 June 2019 (UTC)
I think creating new redirects isn't really a practical solution. Maybe as Fayenatic says, add an optional parameter for the preceding or succeeding category, then have the code get the prev or next categories for that category. This way you don't need to create any redirects and also don't need to use {{Preceding category}} & {{Succeeding category}} to bridge the connections. --Gonnym (talk) 21:04, 18 June 2019 (UTC)
Also, the redirects feature isn't 100% working correctly (from a user-perspective), for example: clicking on the "1887–88" link at Category:1886–87 in English rugby union leads to Category:1887–88 in British rugby union, however clicking on "1886–87" link on that page, leads to Category:1886–87 in British rugby union, a different category. That is very confusing navigation that shouldn't really happen. This is actually a more serious bug as while there isn't an England 1887–88 category for whatever reason, the categories continue right after that year, so instead of showing just a non-linked year, it causes the reader to get kicked out of the correct navigation. --Gonnym (talk) 21:10, 18 June 2019 (UTC)
A separate parameter with the specific category name defeats the whole point of this template.
This feature looks like it should be either:
  1. turned off by default, and turn-onable via |follow-redirects=yes, or
  2. turned on by default, and turn-offable via |follow-redirects=no
If the English/British rugby scenario is in the vast minority of series pairs in Category:Navseasoncats range redirected (base change) (0) (currently 96), I'd argue for default on, otherwise default off. Of course, there are way more series pairs out there without this redirect structure applied than there are the rugby scenario, so I'm leaning default on before even looking. Will check it out soon.   ~ Tom.Reding (talk ⋅dgaf)  01:31, 19 June 2019 (UTC)
Yes, probably best to have default on, and switch it off for e.g. half a dozen English rugby categories surrounding the redirect Category:1887–88 in English rugby union.
Bug-hunting in the current behaviour: Redirects from hyphen to no-hyphen don't work, e.g. at Category:2018 CONCACAF Champions League, the 2017 link is redirected but the template does not follow the redirect to 2016–17. (It's fine the other way, e.g. the 2017–18 link at Category:2016–17 CONCACAF Champions League does follow the redirect to 2018.)
The redirect Category:Fiction set in the 11th millennium -> 11th or beyond likewise doesn't currently work in 10th & preceding. – Fayenatic London 09:50, 19 June 2019 (UTC)
@Fayenatic london: I'll take that as another endorsement to expand use beyond hyphenated cats - currently, only hyphenated cats benefit from this feature.   ~ Tom.Reding (talk ⋅dgaf)  11:02, 19 June 2019 (UTC)
Ah, now I understand what you meant by "all category types". Yes please. – Fayenatic London 11:07, 19 June 2019 (UTC)
 Category-redirect-following now standard for all category types
 |follow-redirects=no allowed   ~ Tom.Reding (talk ⋅dgaf)  15:18, 22 June 2019 (UTC)

Template:R from category navigation

I created {{R from category navigation}} in an effort to keep these cat #Rs from being deleted.   ~ Tom.Reding (talk ⋅dgaf)  23:14, 28 June 2019 (UTC)

@Tom.Reding: In the past I have added "R from" templates to category redirects, e.g. {{R to diacritic}}, but someone reverted me and said that those templates should only be placed on hard redirects, not soft redirects. I can't remember any more details. Perhaps it was to avoid placing entries from category namespace into maintenance cats such as Category:Unprintworthy redirects. If {{R from category navigation}} does not place the redirected page in any categories, perhaps it's not a problem. – Fayenatic London 07:13, 29 June 2019 (UTC)

See Category:2010s in Ohio, which uses {{Navseasoncats}} with no parameters.

But the bolded non-link for the current page is displayed to the right, instead of in the centre. Category:2000s in Ohio in Category:2020s in Ohio both display correctly, so I dunno why 2010s is wrong. Please can it be fixed?

Having the current item consistently in the centre makes the navbar much easier to use. --BrownHairedGirl (talk) • (contribs) 21:35, 24 August 2019 (UTC)

@BrownHairedGirl: this is an artefact of the original template's behavior where only 1 future decade is displayed, as a convenience to the reader. So it was maintained for cases like this, and expanded to some Archive 1#Millennia categories. The idea is that 2030s, 2040s, 2050s, 2060s (or 4th, etc. millenia) categories won't exist for a very long time. You can cancel the offset by using the |max= parameter with any number, and show greyed text up to '2060s' by using |max=2060s, or preferably a larger # like |max=9999.   ~ Tom.Reding (talk ⋅dgaf)  16:35, 25 August 2019 (UTC)
@Tom.Reding, that feature should be disabled by default, and enabled only by a switch (or preferably entirely removed). Having an extant category for one two items after the current is actually the norm, and the jumping around is an impediment to navigation. --BrownHairedGirl (talk) • (contribs) 16:41, 25 August 2019 (UTC)
@Tom.Reding, in this edit[1] to Module:Navseasoncats, I have commented out default offsets unless and until there is an explicit consensus for this perverse behaviour, which disrupts navigation by making the position of the page's decade and makes it jump around erratically as we approach and then pass the current decade. --BrownHairedGirl (talk) • (contribs) 17:32, 25 August 2019 (UTC)
@BrownHairedGirl: I think you've confused/combined the recently discussed left-offsetting behavior with the long-standing right-offseting behavior that has existed since the stable original template. In this old version of Template:Navseasoncats, immediately prior to the mass Lua-ization, see this code:
      -->|{{Navseasoncats/navdecade|{{Navseasoncats/var firsthalf|{{{testcase|}}}}}|{{str left|{{Navseasoncats/var season|{{{testcase|}}}}}|4}}|{{Navseasoncats/var lasthalf|{{{testcase|}}}}}|{{str left|{{CURRENTYEAR}}|3}}0}}<br/><!--
particularly {{str left|{{CURRENTYEAR}}|3}}0 at the end, which has been there since March 2017.
The original (pre-Lua) navdecade, when placed on Category:2000s in Northern Ireland would produce, by default:


1950s • 1960s • 1970s • 1980s • 1990s • 2000s • 2010s • 2020s • 2030s
On Category:2010s in Northern Ireland, it would produce, by default:


1950s • 1960s • 1970s • 1980s • 1990s • 2000s • 2010s • 2020s • 2030s
On Category:2020s in Northern Ireland, it would produce, by default:


1950s • 1960s • 1970s • 1980s • 1990s • 2000s • 2010s • 2020s • 2030s
When migrating {{Navseasoncats}} to Lua, great care was taken to preserve the original behavior where it made sense to, which is, by the virtue of time, the consensus.
What you might be reacting to is the difference between the original display on Category:2020s in Northern Ireland (this difference exists as a safety stop, so as not to force a potentially infinite # of future decades into the show-one-decade-ahead style):


1950s • 1960s • 1970s • 1980s • 1990s • 2000s • 2010s • 2020s • 2030s
with the current one:
If that is what you're reacting to, then we can discuss how best to handle the "next-decade" display (either to continue with the showing-one-decade-ahead method, or to snap 2020 to the center, or by not right-offsetting at all).
If that is not the case, then what I think you've actually done with that edit is to simply confuse the left-offset discussion in the thread above with the right-offset being discussed here.
Either way, you have not restored the consensus, you have instead departed away from it.   ~ Tom.Reding (talk ⋅dgaf)  21:20, 25 August 2019 (UTC)
@Tom.Reding, I am not confusing the two. My change relates specifically to right-offset.
The "old" pre-Lua version you point to is dated 7 April 2019. I dunno how long the broken jumping right offset thing was in place, but i never saw any discussion establishing a consensus to implement this brokenness.
If I have missed something, then please can you give me any pointers to when the old version was broken in this way, and where the consensus discussion was? --BrownHairedGirl (talk) • (contribs) 21:43, 25 August 2019 (UTC)
@BrownHairedGirl: as I said, it has been there since March 2017, prior to anyone else editing the template.   ~ Tom.Reding (talk ⋅dgaf)  22:36, 25 August 2019 (UTC)
Sorry, @Tom.Reding. I missed that link.
But I don't see any discussion achieving a consensus for this perverse jumpiness. --BrownHairedGirl (talk) • (contribs) 22:46, 25 August 2019 (UTC)

@BrownHairedGirl: then I think the solution is a compromise where the the show-1-decade-ahead style is maintained for 2 decades beyond the current, instead of just 1. That maintains the original behavior (even moreso), and limits jumpiness.

Note that it is not a coincidence that this 1-ahead style wasn't discussed until 2019, the end of the current decade. For prior years, the old 1-ahead style presented no problems.   ~ Tom.Reding (talk ⋅dgaf)  23:44, 25 August 2019 (UTC)

@Tom.Reding, that isn't a compromise. It's just a variant of the brokenness, which maintains the fundamental flaw of not keeping current page in a consistent location. --BrownHairedGirl (talk) • (contribs) 00:37, 26 August 2019 (UTC)

Should min & max shorten, or shift, the range displayed?

The parameter |min= has been implemented so that blank spaces appear where earlier dates would be. The range remains centred on the "current" category.

If the range is short, i.e. both min and max are used and they are not far apart, then I support the current outcome.

However, in other cases with just |min=, I would prefer the displayed range to shift so that it starts with the min.

This can be achieved by using the testcase parameter to determine the category at the centre of the template, but then both the testcase date and the current category date are highlighted, e.g. [2]. – Fayenatic London 08:24, 11 June 2019 (UTC)

@Fayenatic london: this seems reasonable, but only for the |min= parameter. Anything else gets more complicated (but is still doable):
Max: Currently, several category types perform a 'right offset' when approaching the current millennium or decade, where the 'current' element is shifted to the right, and always shows 1 element beyond, whether or not it's hidden or greyed. This happens automatically (a feature of the original template wrt decades). The |max= param provides the user with an 'escape' from this default behavior, and will force the 'current' element to always be centered.
Giving |max= this ability would lock-in this shifting behavior, giving the user fewer options, unless a new |max=current value is accepted.
Min: Currently, there is no 'left offsetting' behavior, so |min= simply hides elements lower than its value.
It might be weird to have |max= destroy a 'right offset', while |min= produces a 'left offset'. But, the alternative would be to remove the default right-offset, and require something like |max=current to recover it.
However, min & max regions are different, at least in the case where new future cats will undoubtedly be created (i.e. max is continuously shifting). So having opposite |min=/|max= behaviors also kinda makes sense (I might be biased here due to the original template's behavior).
So the 2 options I see are:
  1. Give |min= & |max= the same behavior, that is, producing the appropriate left/right offset. No offsets will occur by default, only by min/max. In cases of automatically-updated right-offsets, |max=current decade, |max=current millenia, etc. can be used.
  2. Give |min= the ability to induce a left offset, and keep |max= behavior as-is.
I have no problem doing #2 right now, as it's the least disruptive, but I'd like to get a significant amount of input from other editors over a long enough time (RfC-esque) before proceeding with #1.
@Peter coxhead: I think you were the(?) progenitor of the min/max feature (à la Birds described in 1758, etc.). What are your thoughts on this?   ~ Tom.Reding (talk ⋅dgaf)  14:22, 15 June 2019 (UTC)
Ease of implementation was undoubtedly an issue, but I think there are some advantages to readers/users in keeping a standard layout where the year of the category is in the centre, which implies e.g. that min produces blank items to the left. But it's not something I have strong feelings about, so I don't think it really matters. (I'm actually not convinced the categories are particularly useful, so we shouldn't expend too much time on them.) Peter coxhead (talk) 06:44, 16 June 2019 (UTC)
@Tom.Reding: Thanks for giving this careful consideration.
In the past I've argued elsewhere in favour of consistency, including consistent placement of templates, so that a user can click at the same point in a window and expect to move through categories in a consistent way. I see that my suggestion would be a step against that behaviour, and this would be an argument against the suggestion. – Fayenatic London 20:21, 23 June 2019 (UTC)

Default left-offset for select category types?

I'm thinking about using a default left-offset for category types which will only have positive integer elements, like TV seasons, numeric and word ordinals, and roman numerals. This will not/should not interfere with #Should min & max shorten, or shift, the range displayed?.

Currently, the |max= parameter overrides any default right-offsets, forcing the current element into the center. The new left-offset behavior would interact similarly with the |min= parameter.

Before (no left-offset):

Category:Futurama (season 1) episodes:
Category:1st Lok Sabha members
Category:First Dynasty of Egypt:
Category:Deputies of Legislature I of the Kingdom of Italy
  • I
  • I
  • I
  • I
  • I
  • I
  • II
  • III
  • IV
  • V
  • VI

After (left-offset):

Category:Futurama (season 1) episodes:
Category:1st Lok Sabha members
Category:First Dynasty of Egypt:
Category:Deputies of Legislature I of the Kingdom of Italy

Thoughts/questions/suggestions?   ~ Tom.Reding (talk ⋅dgaf)  15:02, 21 August 2019 (UTC)

Courtesy pings to Fayenatic London & BrownHairedGirl.   ~ Tom.Reding (talk ⋅dgaf)  12:15, 22 August 2019 (UTC)
I think it looks better with your changes. No comments on technical matters as I don't know much about the template code. --Trialpears (talk) 13:50, 22 August 2019 (UTC)
  • I prefer the old version, for the consistency of always keeping the current item in the middle of the box.
That means that that I can step through a series by keeping the mouse pointer in the same place, and just clicking when I am ready to move on. --BrownHairedGirl (talk) • (contribs) 14:38, 22 August 2019 (UTC)
@BrownHairedGirl: that is indeed a consideration, and maintaining center makes the most sense for category series with 100s or 1000s+ elements, or elements which can go "negative". However, the selected, non-negative series above all tend to be relatively short: TV series being very frequently never more than 11, and Lok Sabha, dynasties, and legislatures being in the few-dozen range, thus making the left-offset more impactful. The most convenient left-offset would be for TV series (especially since, what long running shows come to mind, The Simpsons has its own custom nav, and EastEnders doesn't use this cat structure from what I can tell).   ~ Tom.Reding (talk ⋅dgaf)  15:00, 22 August 2019 (UTC)
      • @Tom.Reding, I really think that you are massively underestimating the huge usablility advantage of having a consistent location for the "+1", "-1" etc steps. Those allow the user to scroll easily and simply through a series without taking their eye off the content, and that massively boosts ease of use. This proposal brings very little gain: at most it saves one mouseclick at the start or end of series. But it breaks one of the very best things about navseasoncats. I am really really sad about that; it's a big step backwards for usability. --BrownHairedGirl (talk) • (contribs) 01:09, 25 August 2019 (UTC)
  • Thanks, Tom, I find this a marked improvement. For the loss of a minor convenience for editors, there is a worthwhile gain for readers. The “after” appearance makes a lot more sense for TV series and some other cases as suggested. Although I also enjoy the same feature that BHG mentioned, IMHO it is worth losing it in such cases. – Fayenatic London 05:15, 24 August 2019 (UTC)
  • If it is to be done, please can we at least have some means of disabling it? Or preferably a switch to turn it on if desired?
There are plenty of cases where there is a long series by year, but with a defined starting point. I think for example of Category:1921 in Northern Ireland.
Northern Ireland was established in 1921, and it would nice to set a min of 1921 without changing the centering of the display. --BrownHairedGirl (talk) • (contribs) 21:08, 24 August 2019 (UTC)
@BrownHairedGirl: yes, absolutely: the |min= parameter would override any left-offsets and center the current element.
Re: Category:1921 in Northern Ireland: I think setting |min=1921 would do what you want. You'd have to hardcode it into {{Year in Northern Ireland category}} to send |min=1921 to {{Year in country category}} and then to {{Navseasoncats with decades below year}} and finally to Module:Navseasoncats/navyear. Navyear is a {{Navseasoncats}} fork, of course, but it looks like it should handle it correctly.   ~ Tom.Reding (talk ⋅dgaf)  16:55, 25 August 2019 (UTC)
I did that, @Tom.Reding. Now it's broken.
  1. Template:Year in Northern Ireland category: ‎min=1921 [3]
  2. Template:Year in country category/core: ‎ |min={{{min|}}} [4]
  3. Template:Navseasoncats with decades below year: ‎ |min={{{min|}}}: [5]
Now the decade nav is broken on Category:1921 in Northern Ireland. And everywhere else, e.g. Category:1987 in Spain.
Can you fix, or should I revert? --BrownHairedGirl (talk) • (contribs) 17:13, 25 August 2019 (UTC)
@BrownHairedGirl: I can fix it, but it will take some investigating. Will take a look later tonight.   ~ Tom.Reding (talk ⋅dgaf)  17:24, 25 August 2019 (UTC)
Thanks, @Tom.Reding. I will revert my edits for now, so that I don;t leave >30,000 uses of Template:Year in country category broken. --BrownHairedGirl (talk) • (contribs) 17:34, 25 August 2019 (UTC)
 Fixed, I think. Let me know if any side effects occur.   ~ Tom.Reding (talk ⋅dgaf)  17:41, 27 August 2019 (UTC)

Orphaned categories for buildings and structures by year

I have just stumbled across a series of categories created by Vegaswikian in 2015 with a nav template but no parents, e.g. Category:Buildings and structures completed in 1210.

The template is {{10years}} which now redirects to Navseasoncats.

Ah, 10years previously built parent categories that we have overlooked in the updating work. The parameters on the above example are: 

{{10years|13th|Buildings and structures completed in|1210|Buildings and structures by year of completion}}

10years used to include the line 

[[Category:{{{2}}} the {{{1}}} century]]

Parameter 4 used to be a category as well, see old doc page

For the sake of buildings & structures, I have changed {{10years}} for now to transclude navseasoncats instead of redirecting, followed by 

[[Category:{{{2}}} the {{{1}}} century]]
[[Category:{{{3}}} establishments]]
[[Category:{{{4}}}|{{{3}}}]]

However, the establishments category should be replaced by more specific categories in some cases.

@Primefac: I'm not sure if you are watching this page. For info, it was your merge that broke it. [6] – Fayenatic London 22:09, 24 September 2019 (UTC)

This is the reason why we don't usually put categories in templates - if something changes or it gets removed, everything gets borked. I'd say your solution is a good stand-in, though.Primefac (talk) 23:20, 24 September 2019 (UTC)
The above placed too much directly in the [[Category:{{{3}}} establishments]] categories, so I have now built a big switch to generate appropriate parents in each case where {{10years}} is currently used.
@BrownHairedGirl: if you still attend to requested categories, this change is generating many missing ones; e.g. Houses by year of completion has more years than Residential buildings by year of completion, which will now be requesting parents.
I could put in an ifexist test, to use the "buildings and structures" parent if a "residential buildings" category does not exist for that year. – Fayenatic London 22:02, 26 September 2019 (UTC)
@Fayenatic, this is a large categyory set, so the simplest solution is to create a dedicated category template for the set. I'll get onto it now. --BrownHairedGirl (talk) • (contribs) 22:06, 26 September 2019 (UTC)
What, for houses by year? I thought we were moving away from dedicated category templates. I have missed a lot! – Fayenatic London 22:13, 26 September 2019 (UTC)
I never got that memo, @Fayenatic. I think they are a great idea for big sets.
Anyway, I have now created Template:BuildingCompletedYr, and deployed it on Category:Buildings and structures completed in 1211.
i can roll it out in jiffy. Does it look OK? --BrownHairedGirl (talk) • (contribs) 22:23, 26 September 2019 (UTC)
Yes, that looks fine, and it's in one more parent than its neighbours.
It was the red link on e.g. Category:Houses_completed_in_1501 that I was more concerned about. – Fayenatic London 22:39, 26 September 2019 (UTC)
@Fayenatic, I have now rolled out Template:BuildingCompletedYr and also Template:HouseCompletedYr. Hope it all looks Ok now. --BrownHairedGirl (talk) • (contribs) 17:23, 28 September 2019 (UTC)
Ah – I was wrong to put parameter 4 as a category. In the old version of {{10years}} it was only a link at the start of the navbox, not an actual parent category. I will remove it now. – Fayenatic London 22:20, 26 September 2019 (UTC)
Just as a minor note, I've started a TFD with regards to this whole category thing. Your comments there are welcome. Primefac (talk) 01:59, 27 September 2019 (UTC)
(I only recently saw this) Re: the original TfD & categories in templates: I didn't see the extra categorization performed by {{10years}}, but I don't think having categories in templates is an issue, since it makes a uniform category structure easier to maintain & enforce. The practice is very helpful for complicated situations, i.e. {{Category described in year}}, {{NASTRO comment}}, and many others. The problem is/was the vague naming of {{10years}}, and the original TfD was a bit of a misnomer - only changing the navigational component doesn't require a TfD, but a rename to the new house/building templates does. It's unfortunate that no one caught that (myself included), but it's an easy fix given the centralization that cats-in-templates gives, and way better than having to maintain/check the category structure periodically via manual categories.   ~ Tom.Reding (talk ⋅dgaf)  23:06, 5 October 2019 (UTC)

Nations at the XXXX World Championships in Athletics

On category pages which are not every year, but have regular intervals such as Category:Candidates in the 2016 United States presidential election, this template displays fine with every fourth year shown and linked, the intervening three years being omitted. Now consider pages like Category:Nations at the 2015 World Championships in Athletics where every year is shown, even though the IAAF World Athletics Championships have never been an annual event; the years without championships are greyed out. The championships began in 1976 but were irregular (1976, 1980, 1983, 1987, 1991) until 1991, since when they have been held every two years. Is it possible to configure the template to omit the years without championships, since these outnumber the years with championships? Otherwise, there are just two links in the box for the 1980, 1983 and 1987 pages. --Redrose64 🌹 (talk) 11:43, 9 October 2019 (UTC)

Here there is the added complication of a name change from Category:Nations at the 2017 World Championships in Athletics to Category:Nations at the 2019 World Athletics Championships. {{Navseasoncats}} requires category redirects to deal with this. There have only been 19 championships. After your post I have created {{World Championships in Athletics category header}} which just links all of them. In Category:2017 World Championships in Athletics it will produce:
World Championships in Athletics
In Category:Nations at the 2017 World Championships in Athletics:
Nations at the World Championships in Athletics
In Category:Events at the 2017 World Championships in Athletics:
Events at the World Championships in Athletics
The 1976 and 1980 championships were very limited and don't have all the categories. The template will automatically link them if they are created, and also categories for 2021, 2023, 2025, 2027, 2029. I suggest using this template in all the categories instead of Navseasoncats. More functionality in Navseasoncats would still be nice. PrimeHunter (talk) 14:04, 9 October 2019 (UTC)
@Redrose64 and PrimeHunter: I could try to implement an |irregular-interval=on option that searches for existing categories in each direction on-the-fly until the navbox is filled up, and defaults to an increment/decrement of 1 if none are found 10 or fewer away from each element.   ~ Tom.Reding (talk ⋅dgaf)  14:38, 9 October 2019 (UTC)
What about just an |interval= parameter? I noticed on one of the cats (maybe the Olympics?) that it was doing as described above (skipping years), and an |interval=4 could help with that. Primefac (talk) 15:31, 9 October 2019 (UTC)
@Primefac: a hardcoded interval wouldn't find the irregularly spaced categories. Olympics uses a separate cat nav b/c it too is a bit irregular (and the special nav displays dozens of years' worth of games).   ~ Tom.Reding (talk ⋅dgaf)  15:56, 9 October 2019 (UTC)
Fair point, on further reflection I think I was looking at later years for the WCA/WAC as mentioned above. Primefac (talk) 18:12, 9 October 2019 (UTC)
The early Olympics included some Games that were not four years apart, see Intercalated Games. More recently, the Winter Olympics had a two-year interval (instead of four) between 1992 and 1994. --Redrose64 🌹 (talk) 16:35, 9 October 2019 (UTC)
Also, the 1916, 1940 and 1944 Olympics were cancelled. They still have subcategories in Category:Summer Olympics by year but not in other categories like Category:Summer Olympics events by year. Many "regular" events have irregularities. |irregular-interval=on sounds good. It could also be used for completely regular non-annual events so if |interval= is not implemented then maybe it should just be called |non-annual=on. PrimeHunter (talk) 18:55, 9 October 2019 (UTC)
Yes, there were gaps for the two world wars; but they didn't cause a change in sequence - the gaps between 1912 and 1920, and between 1936 and 1948 were whole multiples of four. --Redrose64 🌹 (talk) 19:18, 9 October 2019 (UTC)
|non-annual= could be misleading, and certainly less intuitive and wrong-looking for a passer-by when used on annual event cats which at some distance away from the parent turn into every-2-year events, or skipped a year, etc., so I think |irregular-interval= or |irregular-gap= (to match the existing convention used in the module, documentation, and other existing parameters, but it doesn't sound as good...) would be better as the more general & informative options.   ~ Tom.Reding (talk ⋅dgaf)  19:45, 9 October 2019 (UTC)
Perhaps |irregular-gaps=yes... Anyway, will start on this in the near future.   ~ Tom.Reding (talk ⋅dgaf)  20:08, 9 October 2019 (UTC)

@Redrose64, PrimeHunter, and Primefac: the sandbox now has a working mechanism for skipping non-existing cat years - you can test it via {{Navseasoncats/sandbox|skip-gaps=yes}} to make sure everything is as-expected. If a grey year is shown, that means no cats were found 10-15 cats away (10 away, if the grey element is at the ends of the nav, and 15 away if the grey element is right next to the parent in the center of the nav). Will make live in a day or so if minimal issues.   ~ Tom.Reding (talk ⋅dgaf)  20:25, 10 October 2019 (UTC)

 Now live!   ~ Tom.Reding (talk ⋅dgaf)  14:16, 11 October 2019 (UTC)
Thank you --Redrose64 🌹 (talk) 19:20, 11 October 2019 (UTC)
Sweet. Primefac (talk) 19:24, 11 October 2019 (UTC)

Three-digit years

Can someone add support for three-digit years or otherwise fix Category:604 in Japan? --Numberguy6 (talk) 03:34, 17 October 2019 (UTC)

It's actually not an issue with {{navseasoncats}} but with {{Year in country category}}: if no year is given, it attempts to pull the year using {{title year}}, which pulls four-digit years. I don't have time to play around with that last one to make it pull any number, but in the meantime I've added |year=604 to the category's template call (as it's a supported parameter of {{Year in country category}}). Primefac (talk) 10:37, 17 October 2019 (UTC)

Skip-gaps on decades

Thanks to Tom for taking the template on and doing all the tweaks I never quite got round to doing! <g> One thing I've noticed is that skip-gaps doesn't work on decades eg Category:Mosques completed in the 1830s. Not a biggy, but I thought I'd mention it. Le Deluge (talk) 14:15, 20 December 2019 (UTC)

nth-century foo

Hi Tom.Reding

I have noticed a small glitch in {{Navseasoncats with centuries below decade}}: it works only if the century cats are named "nth century foo" or "Foo in the nth century" ... but it doesn't work if the century category title uses the adjectival form with a dash before "century", e.g. "nth-century foo".

Examples:

Please can this be fixed, if you have time? --BrownHairedGirl (talk) • (contribs) 14:20, 4 March 2020 (UTC)

 Done!   ~ Tom.Reding (talk ⋅dgaf)  16:34, 4 March 2020 (UTC)
Brilliant!
Many thanks, Tom. --BrownHairedGirl (talk) • (contribs) 16:38, 4 March 2020 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Category_series_navigation/Archive_1&oldid=1183647379"